Application delivery switches, also known as Layer 4-7 switches or application delivery controllers, are network devices that optimize the delivery of cloud-based applications (e.g., Web, mobile, etc.) to client devices. Application delivery switches offer features such as server load balancing, data compression, caching, content transformation, application level security and QoS (Quality of Service), and so on. Some application delivery switches, such as the ADX Series of switches developed by Brocade Communications Systems, Inc., provide protection against certain forms of Denial of Service attacks (DoS), including Transmission Control Protocol (TCP) SYN attacks. The mechanism currently implemented in ADX Series switches for protecting against TCP SYN attacks is known as “SynProxy.”
FIG. 1 depicts a typical TCP connection flow 100 between a client device 102, an existing ADX series switch (ADX) 104, and a server 106 when SynProxy is enabled. At step 1a of flow 100, client device 102 initiates a standard TCP three-way handshake by transmitting a TCP SYN packet to server 106. The TCP SYN packet includes TCP connection information (e.g., a sequence number and TCP options) that is generated by client device 102. At step 1b, ADX 104 intercepts the TCP SYN packet and returns a TCP SYN ACK packet to client device 102 that includes an ADX-generated sequence number (also known as a SYN cookie). The SYN cookie, which encodes the TCP options originally sent by client device 102 at step 1a, is generated using an algorithm that is proprietary to ADX 104. At step 1c, client device 102 receives the TCP SYN ACK packet and responds with a TCP ACK packet that includes the SYN cookie value +1. ADX 104 then intercepts the TCP ACK packet and validates the SYN cookie value included in the packet using its SYN cookie algorithm.
If ADX 104 determines that the SYN cookie value included in the TCP ACK packet is valid, ADX 104 concludes that client device 102 is valid/non-malicious. As a result, ADX 104 establishes a first TCP connection with client device 102 and stores state information for this client-side connection (e.g., client-generated sequence number, ADX-generated sequence number, and TCP options). ADX 104 thereafter engages in a second TCP three-way handshake with server 106 (steps 2a, 2b, and 2c). As part of the second TCP three-way handshake, ADX 104 establishes a second TCP connection with server 106 and stores state information for this server-side connection (e.g., server-generated sequence number, ADX-generated sequence number, and TCP options). Finally, at steps 3a and 3b, ADX 104 begins forwarding TCP data packets between client device 102 and server 106. As part of this process, ADX 104 translates, using the stored state information, TCP connection information included in the data packets to bridge the first (i.e., client-side) and second (i.e., server-side) TCP connections.
In some scenarios, it is useful to configure ADX 104 in a “Direct Server Return” (DSR) mode where ADX 104 does not see return (i.e., server-to-client) packets. This allows ADX 104 to handle more connections than possible in the “in-line” mode shown at steps 3a and 3b of FIG. 1. Unfortunately, ADX Series switches currently do not support SynProxy functionality in combination with DSR mode. As noted with respect to FIG. 1, in order to implement SynProxy, ADX 104 must act as an intermediary for all TCP data traffic between client device 102 and server 106 in order to translate TCP connection information between those two entities. In DSR mode, return traffic from server 106 to client device 102 completely bypasses ADX 104, thereby preventing ADX 104 from performing the translation needed for SynProxy.